2024-02-26

Introduzione

La rete CRAN

  • Il Comprehensive R Archive Network (CRAN) è la repository centrale per i pacchetti software del linguaggio di programmazione R.
  • Sul sito ufficiale viene descritto come “una rete di server ftp e web in tutto il mondo che conservano versioni identiche e aggiornate di codice e documentazione per R”.
  • Se state installando un pacchetto R nel modo standard, esso è fornito da uno dei mirror del CRAN.

Il dataset

Il dataset su cui andremo a svolgere l’analisi si compone di due tabelle che descrivono lo stato attuale (aggiornato a luglio 2022) della rete CRAN:

  • cran_package_overview.csv: tutti i pacchetti presenti sul CRAN (una riga per pacchetto).
    package version depends imports license needs_compilation author bug_reports url date_published description title in_cran
    A3 1.0.0 R (>= 2.15.0), xtable, pbapply NA GPL (>= 2) FALSE Scott Fortmann-Roe NA NA 2015-08-16 Supplies tools for tabulating and analyzing the results of predictive models. The methods employed are applicable to virtually any predictive model and make comparisons between different methodologies straightforward. Accurate, Adaptable, and Accessible Error Metrics for Predictive Models TRUE
  • cran_package_history.csv: lo storico delle versioni di tutti pacchetti presenti nella precedente tabella (una riga per ogni combinazione di pacchetto + numero di versione).
    package version date repository
    A3 0.9.1 2013-02-07 Archive
    A3 0.9.2 2013-03-26 Archive
    A3 1.0.0 2015-08-16 CRAN

Analisi storica e generale della rete CRAN

Come è variato negli anni il numero di complessivo di pacchetti?

Conteggio cumulativo dei pacchetti disponibili sul CRAN, per data di prima pubblicazione:

Quanti nuovi pacchetti vengono pubblicati annualmente?

Numero di nuovi pacchetti pubblicati annualmente sul CRAN, per data di prima pubblicazione:

Come varia la frequenza annuale di rilasci di un singolo pacchetto?

Un esempio significativo: dplyr

In generale, come è variata negli anni la frequenza di rilasci dei pacchetti?

Numero complessivo di nuovi pacchetti e aggiornamenti pubblicati annualmente sul CRAN:

Quali sono i tipi di licenza più usati dagli sviluppatori su CRAN?

Quali sono le parole chiave nell’ecosistema CRAN?

Wordcloud generata a partire dalle tagline dei pacchetti:

Dependency Network Analysis

Rappresentazione della rete

  • Rappresentiamo la rete CRAN in termini di un grafo diretto dove i pacchetti sono rappresentati dai nodi e le dipendenze sono rappresentate dagli archi.
  • Nota: prima dell’aggiunta dei namespace (versione 2.14.0 di R) il campo ‘Depends’ era l’unico modo di inserire una dipendenza da un altro pacchetto, dopo l’aggiunta dei namespace il campo ‘Imports’ è diventato il nuovo standard. Per la presente analisi i due campi hanno lo stesso significato in termini di dipendenza e pertanto scegliamo di combinarli.
  • La rete CRAN così costruita non risulta connessa.
  • Riduciamo dunque la rete alla sua più grande componente (debolmente) connessa. (giant component)
  • Infine, per considerare le dipendenze ricorsive calcoliamo anche la chiusura transitiva del precedente grafo.
Otteniamo dunque tre grafi con i seguenti valori:
Graph Nodes Edges Avg_Degree
Full CRAN 18535 94230 10.16779
Giant Component 17004 94213 11.08127
Chiusura Transitiva 17004 540432 63.56528

Nota: degree = in-degree + out-degree

  • Dalla precedente tabella è inoltre chiaro che la rete CRAN è sparsa.

Local Analysis

Quali sono i pacchetti più vulnerabili della rete?

  • Definiamo la vulnerabilità di un nodo X come la percentuale di nodi della rete che verrebbero impattati da una problematica su X.
  • Nel 2016, la rimozione del pacchetto left-pad dalla repository di Javascript (npm) causò ripercussioni su migliaia di progetti (tra cui React), dimostrando le vulnerabilità nelle pratiche di gestione delle dipendenze software.
  • Bug, rimozioni o azioni malevole che coinvolgono un singolo pacchetto si propagano su tutti i livelli di dipendenza, non solo su quelli diretti!
  • Per individuare i pacchetti più a rischio possiamo usare le metriche di centralità.
  • La degree centrality, pur essendo la più semplice, risulta la più appropriata per individuare i pacchetti più popolari le cui problematiche possono impattare il maggior numero di pacchetti.
  • Nota: in questo caso è importante analizzare le dipendenze in senso transitivo: pacchetti con, apparentemente, poche dipendenze potrebbero averne in realtà centinaia transitive.
Dipendenze a confronto:
Package Dependencies (Out-Degree) Transitive Dependencies (Transitive Out-Degree)
wallace 20 242
RISCA 32 234
MinBAR 9 233
ecospat 24 231
TidyConsultant 7 221
Pacchetti più vulnerabili all’interno della rete:
Packge In-Degree Transitive In-Degree Vulnerability (% Nodes)
methods 3569 14362 84.5
utils 3275 14352 84.4
stats 5361 13328 78.4
grDevices 1480 12087 71.1
graphics 2318 11567 68.0
grid 535 8790 51.7
lattice 369 8536 50.2
magrittr 1775 8335 49.0
Rcpp 2498 8200 48.2
rlang 1626 8123 47.8
Pacchetti più vulnerabili all’interno della rete (escludendo i pacchetti ‘core’):
Packge In-Degree Transitive In-Degree Vulnerability (% Nodes)
lattice 369 8536 50.7
magrittr 1775 8335 49.5
Rcpp 2498 8200 48.7
rlang 1626 8123 48.2
glue 481 7962 47.3
R6 409 7697 45.7
Matrix 1158 7393 43.9
crayon 272 7100 42.2
lifecycle 180 7075 42.0
pkgconfig 6 7075 42.0

Group Analysis

Esistono delle comunità distinte all’interno delle rete?

  • Nell’ambito delle reti software ci si potrebbe aspettare che si formino degli ecosistemi (o comunità) di nodi che condividono simili applicazioni o ambiti d’uso.
  • Esistono diversi algoritmi per l’individuazione delle comunità, uno dei più popolari è il metodo di Louvain.
  • Nota: ovviamente in questo contesto non usiamo la chiusura transitiva.

Quali sono le comunità più grandi?

Comunità con almeno l’1% dei nodi (in ordine decrescente di grandezza):

Size (% Nodes) Most Vulnerable Description Keywords
19.9 utils, stats, grDevices, graphics analysis, regression, estimation, functions
18.6 magrittr, rlang, glue, R6 api, interface, analysis, tools, client
14.6 methods, Rcpp, Matrix, codetools analysis, bayesian, model
10.3 MASS, parallel, iterators, foreach analysis, regression, estimation
6.3 grid, colorspace, RColorBrewer, farver analysis, ggplot, model
6.0 isoband, sp, abind, png spatial, analysis, tools, functions
6.0 tools, viridisLite, fastmap, htmltools shiny, analysis, interactive, create
3.7 mvtnorm, coda, mnormt, psych bayesian, analysis, regression
3.3 zoo, Formula, sandwich, xts time, series, analysis, regression
2.8 lattice, nlme, xtable, lme4 analysis, regression, linear, model
2.5 labeling, plyr, bitops, XML analysis, interface, text, package
2.3 data.table, backports, checkmate, MatrixModels functions, services, analysis, interface, mlr
1.5 ape, deSolve, permute, vegan phylogenetic, analysis, trees, comparative
1.4 reticulate, BiocManager, Biostrings, tfautograph analysis, interface, gene, sequences

Global Analysis

La rete CRAN ha le caratteristiche di “Small World”?

Sappiamo che, in generale, il fenomeno di small world richiede due caratteristiche:

  • High clustering: il coefficiente di clustering C della rete deve essere significativamente maggiore del coefficiente di clustering C_r di un grafo casuale equivalente (generato secondo il modello Erdős-Rényi).
  • Low average shortest path: la media delle distanze geodesiche tra i nodi della rete deve essere nell’ordine di log(N), dove N è il numero di nodi della rete.
Verifichiamo dunque se la rete CRAN presenta queste caratteristiche:
Graph C C_r Mean Geodesic log(N)
CRAN (Giant Component) 0.0043094 0.0007129 2.981281 9.741204

Dalla tabella è possibile notare che la rete CRAN soddisfa le caratteristiche di small world.

Nota: le misure in tabella si riferiscono alla controparte indiretta del grafo.

La rete CRAN segue una “Power Law”?

Possiamo verificare se la rete CRAN segue una power law osservando la distribuzione dei gradi dei suoi nodi:

Già osservando l’istogramma possiamo ipotizzare che la distribuzione segua una power law, ma verifichiamolo formalmente.

Sappiamo infatti che se una distribuzione segue una power law allora anche la CCDF della distribuzione segue una power law (ma con esponente di un’unità inferiore).

Dunque, se tracciata su una scala log-log, la CCDF di una power law apparirà come una linea retta:

La precedente linea non risulta però perfettamente retta, infatti in questo caso in-degree e out-degree rappresentano due concetti diversi:

  • in-degree rappresenta il numero di pacchetti che richiedono un dato pacchetto per funzionare.
  • out-degree rappresenta il numero di pacchetti di cui un certo pacchetto ha bisogno per funzionare.

Dunque, come ci si potrebbe aspettare, la rete CRAN segue una power law soltanto per quanto riguarda la distribuzione degli in-degree:

Dal precedente grafico si evincono due importanti caratteristiche della rete CRAN: - Il comportamento scale free degli in-degree indica un’alta riusabilità dei componenti. - L’elevato troncamento degli out-degree pone un limite alla complessià delle dipendenze dei singoli pacchetti.

Le caratteristiche elencate sono entrambe positive per una rete di dipendenze software, ma è altresì importante notare che, come visto prima, un’alta riusabilità aumenta anche la vulnerabilità dell’intero sistema in quanto il malfunzionamento di una piccolissima frazione di pacchetti può portare al malfunzionamento dell’intero sistema.

Infine, è ormai chiaro che la rete CRAN risulta essere una preferential attachment network. Infatti i pacchetti con un numero maggiore di connessioni (dipendenze inverse) hanno una maggiore probabilità di aumentarle ulteriormente nel caso in cui nuovi pacchetti vengano aggiunti alla rete.

Grazie dell’attenzione!